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Sculley reorganizes Apple, Inc. 

Apple's Macintosh division finally got its balloon punctured May 31 when 
John Scully, Apple's president announced a reorganization of the company 
TWo weeks later, on June 14, Apple announced it was moving the production 
of the Apple lie to its "Macintosh" plant in Fremont Calif; moving production 
of all lies to its factory in Singapore; and firing 21 per cent of its work force. 
Sixty per cent of the firings are among manufacturing workers. All Apple 
factories, except the Fremont and Singapore plants and one in Cork, Ireland, 
will be closed. 

Apple's board of directors decided to allow Sculley to reorganize the 
company fii^om two product-oriented divisions (Apple II and Macintosh) into 
two /unctiofhoriented divisions (operations and marketing). In the shuffle 
Steve Jobs, founding father and chairman of Apple, lost his operating 
responsibilities, (previously he had direct control over both the manufecturing 
and marketing of the Macintosh). He remains chairman of the company 

Del Yocam, the Apple veteran who had been in charge of the Apple II 
division, is now head of all operations, including manufacturing, distribution, 
and new product development Yocam, 41 years old, joined Apple in 1979. 
Yocam's accomplishments at Apple include coordinating the manufacturing 
changeover fii^om the Apple II-Plus to the Apple He in late 1982, and 
overseeing the development and introduction of the Apple lie. In a Wall 
Street Journal article on Yocam and Apple (June 7, page 18), Steve Wozniak 
said that during Yocam's tenure, "the direction of the Apple II division is the 
best it has been in five years." 

Jean-Lx}uis Qassee will work for Yocam as head of product operations, 
which includes new product development In 1980, Qassee formed an Apple 
distributorship in ftance. The distributorship later became Apple France, a 
company subsidiary. Under Qassee, Apple France captured about 30 per 
cent of the French personal computer market more than IBM and more than 
Apple's share in other countries. In its June 10 edition, InfoWorld (page 15; 
caution, this article was written before Sculle/s reorganization and has 
Qassee's position wrong) describes Qassee as an intellectual and a visionary 
— a more mature French counterpart to Steve Jobs. However, he is also said 
to be an experienced turnaround manager and to have an ability to satisfy 
dealers. 

Apple's new marketing division will be headed by William Campbell, who 
was recruited by Sculley in late 1983 from Eastman Kodak. At Kodak, 
Campbell was director of consumer product marketing in Europe. At Apple, 
he had been directly associated with neither the Apple II nor Macintosh 
divisions, but was the top marketing person on Apple's corporate staff. 

Sculle/s reorganization is the result of a leveling-off in the ^owth rate of 
personal computer sales. Apple's sales are actually higher than last year, 
however, they are not as high as planned. (In 1984 Apple's revenues were 54 
per cent higher than the previous year. 1985's growth in sales will be 
considerably less.) Because of costs associated with the reorganization, 
Apple expects to post its first quarterly loss at the end of June. 

The slowdown in the growth rate of computer sales is affecting the entire 
industry. The usual profit growth Wall Street has become accustomed to just 
isn't materializing this year. IBM has announced that it expects no change in 
profits during the first nine months of 1985 compared to the previous year. 
Apple expects to earn a lower profit this year than last Wang, for the first time 
in its history, is predicting it will earn no profit at all 

The slowdown has hurt Apple more than IBM because the situation is 
worse in the consumer market where Apple is strongest than in the 



business market where IBM leads. Much like just before the IBM PC jr 
appeared on the scene, many consumers are delaying computer purchases 
until new, Macintosh-like computers announced by Commodore and Atari 
are on dealers' shelves. Look for Apple II sales to surge— and shortages to 
develop— when those machines finally hit the streets, just as happened 
when the PCjr came out of IBM's closet 
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Aj^tehasn'taskad for my advice (merely 
two subscriptions have been paid for with 
checks ft-om Cupertino . . . ) but let's take a 
look at the Apple II family and send a few 
thoughts about the future back to California 
anyhow. 

For six years now Apple's management 
has been trying to build a computer better 
than the Apple II. During those six years 
the scorned II has provided Apple with 
millions of dollars for research and devel- 
opment The money was spent on the 
Apple III and Lisa, both nowdeai>|ind the 
Macintosh, which isn't dead yet In all 
these years, afi^r all this money, only the Apple II has evier shown a profit 

The message here is that computer buyers are not looking for the fastest 
chips, the biggest memory, the best graphics, or the largest disk drives. They 
aren't looking for "user-ftiendliness" that sacrifices programmability and 
speed for mice and bit-mapped trashcans. 

Buyers are looking for tools they can use. The Apple II has plenty of power 
to be useful. So have several hundred other machines. 

The significant thing about the Apple H is the community of people that 
has sprung up around the machine, teaching other people how to use it 
developing applications for it designing hard and software for it It is this 
community that makes the Apple U a significant machine. It is this 
community that is the driving force behind Apple Inc's phenomenal growth. 

The fastest road to glory for Apple is to continue a slow evolution in the 
Apple 1 1 family The fastest road to ruin is to develop machines that abandon 
this community in Apple's technological wake. 

The Apple II community is averse to walking away from its hard-earned 
understandingof the Apple II. If the community can't leverage its accumulated 
knowledge into better explanations for new users, better applications, and 
better hard and software, a new machine will not get its interest If we are 
forced to walk away from the Apple II, we are as likely to walk in the direction 
of IBM or Atari as in whatever direction Apple Inc. is "leading," 

A slow evolution would allow features to be added to new high-end models. 
But the compatibility of these new models with previous models is a far more 
important issue than the latest technological wizardry. 

Compatibility means a microprocessor based on the 6502, ^plesoft 
in ROM, Apple ii-compatible memoiy mapping, ^ple il-compatible 
slots, and 5-1/4 inch disk drives as standard equipment. It means 
computers that will start up DOS 3.3 disks with no special handling. 
And it means reasonable prices. Any computer that has these features 
will be a success in the marketplace. 
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from its base in education, the home, and small business, the Apple H's 
market could be gradually broadened to include larger organizations by the 
introduction of more powerlui machines and software. The technology is 
available to build a family of computers around the Apple II. 

At the top could be a true 16-bit computer based on the 65816 miaopro- 
ccsson It should have a ton of memory. But it should also have some 
standard Apple II slots. How about a souped-up version of AppleWorksto go 
with this machine, with maaos, graphics, terminal-emulation software, and 
desktop accessories? But be careful, Apple. Unless this machine can also 
boot and run APFLEVISIOM, the early Integer Basic hl-res graphics and 
sound demonstration program, it's not an Apple II. 

In the middle could be a 16-bit " computer based on the 65802, The 
65802 has internal registers 16 bits wide but reads and writes to and from 
memory 8 bits at a time (just like the IBM-PC). Because of this, and because 
(like the 65816) it acts like a 6502 when you turn it on, you can actually plug 
one of these into an existing Apple II. Imagine a machine with 256K to 1 
megabyte of memory built around one of these at tfie price of today's ^ple 
He. But if s gotta run APPLEVlSIOli. 

Then there's the lie and lie Gradually falling prices and the inclusion of 
AppleWorks in the box with the computer could extend the lives of these 
machines beyond anything IBM ever dreamed of. And we already know they 
runAPPLEVISiOa 

In addition to computers, Apple can look for growth in the peripherals 
market. Mth the exception of the LaserWriter, Apple has shown no 
technological leadership at all in the area of printers, modems, or monitors. 
An add-on 800K 3-1/2 inch drive, at a good price, could certainly be a 
successful Apple 11 peripheral (but its incompatiblity with existing software 
would crush the sales of any "Apple 11" it was built into). 

And how about special private label models of the II that could be sold to 
companies that want to build other things out of them? This is a market 
Apple has totally ignored. Since starting Operi'/^ple, I've con-esponded with 
people who have Apple lis at the center of elcxAronic weighing systems, cash 
registers, and library circulation ^tems, among others. These people all 
sell products that happen to include Apple lis. Because there are so many 
people in the worid who know how to make an Apple II dance, there is a 
tremendous unexploited mari^et here. It's easy to imagine Apples hidden 
away at the heart of security systems, engine or blood or fertilizer analyzers, 
or (dare 1 say it?) telephones. But Apple has to leam to pursue these "low- 
tech" Apple 11-based markets and stop wasting its resources trying to seduce 
the fortune 500 with the Macintosh. 

Does Apple's sudden reorganization mean the people who run it have 
finally realized the potential shyly hiding inside the Apple II? We'll have to 
wait and see, 
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The /RAM disk that ProDOS automatically installs on 128K Apples is a 
feature that can be hard to take advantage of. If you have a very big program, 
you can theoretically split the program into sections, put the sections on / 
RAM, and use the CHAin command to quickly move from one section to 
another Or, if you have a small program but a large data file, you can 
theoretically put the data file on /RAM and access it at the speed of light 
instead of your disk drive's 300 RPM. 

To change these ideas from theory to practice, however, requires a 
program that will copy files from disk to /RAM when you start; up your 
computer, and from /RAM back to disk just before you turn it off. You can use 
the ProDOS FIlMfor this, but it doesn't give the kind of automatic operation 
most computer users are looking for. 

Several subscribers have written asking for a Basic program that can copy 
files from disk to /RAM and back. Such a program turns out to be extremely 
simple to write because of some powerful parameters Basicsystem provides 
for binary file commands. Since many people haven't discovered this power 
yet lets examine these parameters and write a basic Basic copy program for 
ProDOS. 

Downloaded from ww\ 



ProDOS and Basic«systein version numbers. Before we start, let s talk 
about the various versions of ProDOS, since there are some version 
differences in how the binary commands work. Before we can even talk about 
versions, however, let's talk about something even more elementary— the 
difference between the ProDOS kernel and Basicsystem. A major fault with 
the ProDOS documentation, beginning with Apple's stuff and extending right 
through almost everything else that has been written, is a failure to 
distinguish between the ProDOS kemal and Basicsystem. 

The ProDOS kemal lives in a file called PRODOS. I've found four official 
versions in my disk library (there may be more); 101 (l\IAPm), 10,2 (15- 
FEB^), U (17-AUQ-84), and lU (18-SEP-84). You can tell which version is 
on a disk by cataloging the disk and looking at the date the file was last 
modified (not created, that's when the TILER put it on your disk). You can also 
tell by booting the disk and watching the screen carefully The version 
number of the ProDOS kernel and a copyright notice appear for about 4 
seconds while the disk is booting. 

ProDOS is accessed through a machme language interface. The ProDOS 
kernel supports no other language, only machine language. It has commands 
such as seLfdeJnfo, geLeof and alloaJntermpt It doesn't know controI-D 
from synchronous idle. It doesn't even have a CATALOG command. 

Basicsystem lives in a file called BASICSYSTEM, It's been officially 
released in only two versions that I can find; 10 {15-n0V-B3) and (15-MAR-^) 
and U (18-JUW-84). You can tell which version is on a disk by cataloging the 
disk and checking the date. You can also start up BASICSYSTEM in such a 
way that it can't find a STAFTUP file (temporarity change the name of the 
STARTUP file to something else); Basicsystem prints its version number 
after booting if there's nothing to start up. 

The commands everyone refers to as "ProDOS" commands, such as 
CATALOG, BLOAD, and PREFIX, are really "Basicsystem" commands. 
"Basicsystem" is the connecting link between Applesoft and the ProDOS 
kernel. Basicsystem provides a DOS 3.3-like control-D interface for Basic 
programmers working under ProDOS. The likeness to DOS 3.3, however, is 
not a feature of ProDOS; Logo runs under ProDOS and can't even print a 
controI-D. 

Binary file anatomy and execution. Binary files typically hold either 
machine language programs or high-resolution graphics images. They're 
the ones identified by B//Yin a disk's catalog. 

Binary files can be executed with eitiier the DASH ("-") or the Mm 
command, like this: 

- /tlY.DISK/MY.PRQGRRM 
BRUM /MY.DISK/MY.PRDGRfifl 

These commands work best, of course, if the file really is a machine 
language program. If the file contains a graphic or hides some other type of 
data, an attempt to execute it will usually make your computer lock up or 
crash into the Monitor. 

Think of binary files as "snapshots " of portions of your computer's 
memory. They are very similar to the photographic images a Kodak takes. 
However, they have one significant advantage —you can snap them back into 
memory the next day and take up where you left off. That's something we 
can't do yet with my baby pictures. 

When you take a snapshot of memory you have to specify what address 
rangeyou want to take a picture of. Basicsystem provides three parameters 
for doing this. The A parameter (address) specifies where in memory the 
range starts. You specify i^ere it ends with either the E parameter (end), 
which gives the address of the last byte in the range, or with the [.parameter 
(length), which tells how long it is. 

Basicsystem stows this memory-position information, along with other 
data about tiie file, inside the disk's directory. The 80-column ProDOS 
CATALOG will dig it back out for you. Here's a ProDOS catalog with a file 
holding a hi-res picture. The address of the file is given (in hex) under 
"subiype," the length is ^en (in decimal) under "endfile." 

NAME TYPE BLOCKS MODIFItD CREATED ENDFILE SUBTYPE 

PRETTY. PIC BIN 1? 31-JUN-85 7:47 31-JUN-B5 7:4? B192 fl=t2000 

If you use the DASH command to execute a program, Basicsystem will use 
the addresses in the directory to determine where to load the file. The same 
thing happens with the BRUH command, although widi BRUM you can 
override the "default' addresses with the A or t parameters. 

Get a load of this. Binary snapshots can be loaded into your computer 
without executing tiiem with the command BLOAD. A feature found in 
Basicsystem's BLOAD and Bf^H commands that s not in DOS 3.5 is that you 
f^plezOnline^com 
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can use tt\e L (<qx t] paTametet to Voadjusl part ot abinat^ fi^^-^ou dou' thave 
to load the whole thing. If you use the L parameter with 5L0AD or BRUM 
under DOS 5.3 you get a syntax error. 

Another difference from DOS 3^ is the Basicsystem file type parameter, 
X This parameter can t>e used ^th BLOAD ( but not with BRUI1) to load my 
type of fiie into memory as if it were a binaiy snapshot This is a very powerful 
feature; without it our soon-to-follow basic Basic copy program would be 
impossible. 

The binaiy savior. Binary snapshots are created with M command 
BSAVE. If the file doesnt already exist you have to specify an address range 
for the picture. Here's an example: 

BSWE PRETTV.PIC,fl$2«00,LS2000 
or 

BSflVE PRETTY. PIC,fiB132,ES3FFF 

When the file doesn't already exist BSAVE will create a new one and tuck 
your snapshot into it An interesting side effect of using BSAVE with the file 
type parameter, howeven is that with T BSAVE can't create new files. It returns 
a PATH nor rouno error, even if the file type you specify is 5m. 

If the file does already exist on the other hand, Basicsystem has some 
more magic for us. Unlike DOS 3.3, Basicsystem doesn't make you specify 
an address range for existing files. BSAVE ?HETTY,PIQ works just fine— 
Basicsystem will use the existing address and length information. 

The big difference between Basicsystem 10 and U is what happens when 
the file already exists and you specify a different address range. VlTith 10, as 
with DOS 3.3, the old address range is thrown out and the new one is used. If 
the new range is shorter than the previous one, any unneeded disk blocks 
are released. With H on the other hand, the old address range is retained. (If 
the new material makes the file longer however, the file length will be 
increased as required) 

Sandy Mossberg (letter in Ifibtle, June 1985, page 7) and Glen Bredon 
(letter in Open-Apple, May 1985, page 40), both competent authorities on 
such stuff, say this is a bug in Basicsystem H 

But Ken Kashmarek and Cecil FVetweli, also competent authorities, argue 
in tetters to Open-Apple that it's not a bug at all. More about this is a 
moment 

It's painful to B misunderstood. First, though, let's examine the most 
misunderstood little creature in all of Appledom, the B (byte) parameter. B 
got off on the wrong foot in the original DOS 3.3 documention. The DOS 
Manual That book had a two-page section on the B parameter that began, 
' note: the following section is not for beginners...", and which consisted 
mostly of warnings about all the problems you could aeate by using the B 
parameter inappropriately. 

In the later DOS Programmefs Manual this two-page section is missing. 
What little information on B that is presented in this book is onfy partialfy 
correct 

In Basic Programming with ProDOS, the B parameter loses even its entry 
in the index. No examples of how to use the parameter are given. And the 
tradition ccmtinues in Gaiy Little's ProDOS series running in il+ and in Lee 
Swoboda's series running in mCider— neither of them say much about B 
and both of them have its maximum value wrong. 

The B parameter allows you to quickly and easily move the position-in-file 
pointer to any byte in a file. Unlike DOS 3.3, Basicsystem allows you to use B 
with BLOAD and BSAVE. B can also be used (under both DOS 3.3 and 
ProDOS) with READ and WRITE, but this is more complicated; for a complete 
discussion see the August 1984 DOStaikiin Softalk, page 43). 

When you use B and L (or E) together, you suddenly have some amazing 
new binaiyfile-handling abilities. You can put several graphics in the same 
file and access them one at a time. You can put several programs in one file, 
too. 

The best part, though, is using B and L (or E) and T together at the same 
time. This allows you to read and write records to and from any part of a text 
file at binary-file speeds, for example, imagine a hard-disk based data flte 
with 1000 records, each 1200 bytes long, fteading in a 1200 byte record can 
take awhile with IHPUT; but imagine how long it would take \^th: 

PR^T OSrBLOftD OftTft.FILE, TTXT, flS400e, L1200, B";R*1200 

That command would load the 1200 byte record specified by R Into the 
memoiy range beginning at $4000 in a fraction of the time inPtJT would take. 

But consider for a moment the equivalent command for saving to the data 
file, and you'll understand why our correspondents Kashmarek and Flretwell 
don't see a bug where Mossberg and Bredon do: 
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If Basicsystem's BSAVE works like DOS 3.3's in this situation, all the data 
in the file beyond the current record gets cut off and thrown away That's not 
an acceptable alternative. 

But, on the other hand, if BSAVE doesn't adjust the length of binary files, 
you'll often end up with files that havejunk tacked on the end— as frequentiy 
happens with text files. 

If the ProDOS modification team thinks like I do, someday they'll fix BSAVC 
so it cuts off the end of the file, but only if no file type parameter is given. 
TVeat the T like Hr. X I say, and don't cut anything firom files vAien a BSAVE 
uses it 

Xerox will tove this, flow that eveiybody understands the magic of 
BLOAD and BSAVE under Basicsystem, lets write a quick routine for copying 
files from disk to /RAM and back. We'll BLOAD the files with one prefix, then 
quickty BSAVE them with another prefix. Just one problem; inhere in memory 
do we load them? Our program and its variables will be in memory 
somewhere; it's important that we don't load a file on top of anything. 

Refer back to the memoiy map in our January article "Taking a poke at the 
Qarbageman" (page 4). The map shows that there's an area of firee memoiy 
between a Basic program's variable tables and its string storage area. The 
map shows what bytes to peek at to find the boundaries of this fi-ee area. And 
the article explains that the PRE command makes this area as large as 
possible. 

So, to get some memory we'll execute a PRE command; peek into the 
location known as STREflD at 109-110 ($6D-6E) to getan Address parameter; 
and peek into tiie location known as FRETOP at 111-112 ($6F-70) and 
subtract 1 to get an End pEffameter. How about 

10 REM »** BASIC. COPY *»« P *7 ^ 

100 DS-CriR$(4) 

110 PlJ-"/JLV/" : REM prefix of volume that files are to be copied FROd 

120 P2$=''/RRfl/" : REM prefix of volume that files are to be copied TD 

130 FfsTILEX" : TSs-TXT' : GOSUB 400 : REM namBS and types of 
140 r$=TILE2'' : TS=*'BflS" : GOSUB 400 : REM files to be copied 
150 n^TlLZl" : TS^-BIN- : GOSUB 400 

200 EHO 

400 B=0 : fl-0 : E=0 : L=0 : REM ImpDrtant— messing with this line can tie fatal 

410 PRINT Dir'FRE" 

420 fl=PEEK(109) + PEEK ( 110 )*25G 

42S E=PEEK(111) + PEEK(112)»2SG 

430 ONERR GOTO 500 

440 PRINT D$; "CREATE"; P2f;F$; ",T";T$ 

450 PRINT 0$;"BLOftD"; P1$;F$; \T";T$; "^fi'jfl; ".E^^E-l; ".B-jB 

4G0 L=PEEI<( 48855] + PEEK ( 49060] *25G 

470 PRINT Of; 'BSPiVE"; P2$;F$; ",T ";T$; ",L";l; '',B'';B 

480 IF L=(E-fl) THEN e=B+L : GOTO 450 

490 POKE 216,0 : RETURN 

500 IF PEEK{222)=19 THEN PRINT D$; "DELETE"; P2S;F$ : RESUME 
518 IF PEEK(222J=5 THEN CfiLL -32aB : GOTO A5Z 

520 PRINT "ERROR tt-;PEEK(222);" IN LINE '';PEEK{21fl} + PE£K(219)*25G 
530 END 

Don't mess with line 400. It makes sure all the variables used in the 
routine have been allocated space in memory beforevie find out how much 
free space we have. If a variable is used for the first time a/ierwe do our peeks 
to determine A, the variable table will get moved up into our free space with 
not inconsequential consequences. 

Since BSAVE— when used with the T parameter— can't create files, we 
have to CREATE a file for our /RAM copy in line 440. If die file already exists, 
(as it most certainly will when we copy from /RAM back to disk), a DUPICATE 
PATHriAMEenror will occur and line 430's OriERR will take us to line 500. The 
error code for duplicate pathname is 19; line 500 deletes the file and 
RESUMES back to the CREATE command. 

Une 450 BLOADS the file. If the file is s/iorterthan what we have specified 
with the E parameter, no enror will occur. If it is longer, E sees to it that we load 
on^ as much of the file as will fit Loading begins with the first byte of the file 
(b^eO). 

Une 460 peeks at a Basicsystem location known as RWTRAHS at 48859- 
60 ($BEDB-DC) to find out how many bytes actually were loaded by the 
BLOAD command. (The equivalent location in DOS 3.3 is 43616-17 ($AA60- 
61); the actual loading Address can be found at 48855-56 ($BED7-D9), this is 
equivalent to DOS 3J5's 43634^5 ($AA72-73).) 
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Line 470 BSAVES the file using it's actual Length, This Length will transfer 
to the new copy of the file correctly. However, if the file really is a binary file, the 
copy's loading Address, as shown in the catalog, will be wrong. So will the 
record length (R=) of text files. Basicsystem 10 shows the address we used in 
parameter A, not the (Hie on the original file, for both Address and record 
length. Version H on the other hand, sets both to zero. ( Incidentally, if you tiy 
to BLOAD a file with a loading address of zero you get a HO BUFFERS 
AVAILABLE error. This message is quite confusing, because the problem has 
nothing to do with buffers; the ProDOS kernel simply refuses to load files into 
that address because the area is "protected" in the "system bit map.") 

These problems are fixable, but not this month. For now, always specify A 
and L when using files copied by this techinque. 

Line 480 looks to see if we got the whole file or if there is more of it still on 
the disk. If the actual Length we got was less than the End minus the Address, 
we got it all. If these values are equal, the file was either exactly the same size 
as our fi^ee memory area, or there is more. In either case, adjust the B 
parameter so it points to the first byte we didn't get and go back to line 450. 

The second time we execute BLOAD, the B parameter points well inside 
the file. We'll get a bunch more of it' this will continue until we have the whole 
file. If we should run aaoss a file that accidentally has the same number of 
bytes as our free space, line 450 will get an EHD OF DATA error. Line 450's 
OliERR will then take us to line 510, where we dear the stack (see January's 
Digging !nto DOS, page 2), and return to the caller. 

There you have it— a basic Basic copy routine. 

This one didn't stick. In preparing this article, I took a look at what at! the 
books 1 have on FroDOS had to say about binary files. This brought me face- 
to-face with the fact that Chapter 6 of Prentice-Hall's Inside Apple 's ProDOS is 
an idea-for-idea rip-ofi'of Chapter 9 of Apple's own Basic Programming with 
ProDOS. For example, compare these two sendees: 



Because of the way ProDOS uses memory, it is difficult to predict which 
parts of memory are free to hold machine-language routines. 

Because of the way ProDOS dynamically allocates and deaHocates 
memory for file buffers, it is somewhat more difficult to manage memory 
and guarantee which parts of memory will be free to store and protect 
madiine-langus^e routines. 

The lirstscntence is fi-om Apple's book (page 154), the second kmn Inside 
Apple's ProDOS (page 100), which was published by Reston Publishing 
Company, a division of Prentice-Hall. The whole chapter is like that I didn't 
compare the entire contents of tiie two books, only this chapter; 1 don't mean 
to say tiiere is anything iileg3l about this ^ of paraphrasing, because I 
don't think there is. 

The problem is that it's a disservice to both customers and to legitimate 
writers when publishing companies flood the market with this kind of aap. 
Compare the two sentences and you'll see Apple's original wording is much 
clearer. In Prentice-Hall's version, try to figure out what managing memory is ' 
more difficult than. It makes you wonder whether the book was even copy 
edited 

As it happens, both books do an inadequate job of explaining how to 
install machine-language routines in memory (See So^Uc June 1964, page 
159, for an adequate explanation.) 

As a book buyer, you shouM be aware that Prentice^all's publishing 
philosophy is to tiirow lots of books on the market and see what sticks. Some 
of them turn out to be quite good, for example, tiie Quality Software books 
published by Brady Communcations, also a division of Prentice-Hall 
{Understanding the Apple He by Jim Sather and Beneath Apple ProDOS by 
Don Wortii and Pieter Lechner). More of tiiem, however, turn out to be 
medioore at best including Inside Apple's ProDOS. Buyer beware. 




Adding commands to Basic.system is becoming a good-sized cottage 
industry. Apple's FroDOS development team put some neat features in 
Basicsystem that allow any number of special routines to be hidden away in 
memory and called as DOS commands. Lots of stuff that uses this feature is 
coming out of the woodwork and much of it is quite interesting. 

Qien Bredon (321 State Rd, Princeton, ru 08540), author of tfie Meriin 
assembler, has a $20 disk he is selling himself called /PROCMD. It includes a 
number of Applesoft editing and debugging utilities, and tiien some. The 
disk has a GPLE^like editor; renumber, hold, and merge commands; cross- 
reference and cun^ent value dumps for variables, as well as a value tracer tiiat 
works while a program is running; copy, sort, type, memory dump, date, and 
print-using commands; and a double-high resolution graphics package. The 
documentation is included on tiie disk. (Incidentally, Glen wrote to say tiiat 
he documented the dianges in lie Applesoft that we trekked through here 
last month well over a year ago in the Applesoft source code tiiat comes fi-ee 
witti the Merlin-Pro assembler —$70 from Roger Wagner Software, P.O Box 
582, Santee,CA 92071) 

A routine for stepping through ProDOS directories is part of another 
interesting disk that appeared in my mailbox. It's called Developer Disk #1 
($7 from Nite Owl Productions, 5734 Lamar Ave, Mission, KS 66202). This 
disk has a bunch of routines to assist in the development of programs for the 
Fiight OwlJoumal a magazine-on-disk scheduled to begin publication tiiis 
montti. The command that steps tiirough directories is called ' Quick Index.' 
It allows users to quickly find and select a file even if it's buried inside 
multiple subdirectories. This is a neat feature we should see more of in 
ProDOS software. A QETPILE command on this disk allows such selection 
from witiiin Applesoft programs. The name of tiie file tiie user selects is 
returned in a string variable. Also on tiiis disk are three new IHPUT 



commands. One simply accepts commas and colons; tiie other two support 
ttie underiine cursor and delete key, as well as provide QPL5-llke string 
editing functions. One of these is for inputting new strings; the other allows 
the user to edit existing strings. 

The ability to mix routines from various authors is tiie best part of 
Basicsystem's added commands feature, for example, you can mix Mite 
Owl's input-anyUiingOETSTRcommand witti Bredon's print USIMQ command 
to quickly add tiie two most needed features to Applesoft. Very littie memory 
is used because tiie commands can be added independently of the rest of 
Uie commands tiiey come witti. Authors of such routines have to know what 
tiie/re doing, however, to get routines to mbt. Several extira steps are 
required to assure a routine will work witti otiiers, 

Unfortunately, Apple has never documented what tiiese steps are. (In feict 
Apple's own added'command routines, /f£LPand APA which are on the / 
EXAMPLES disk that comes with Basic Programming with ProDOS, don't 
take these steps and can't be combined witii otiier routines.) The June 1984 
DOStalk (SoftalK page 157), however, did list the required steps and 
pompously called tiiem ttie DOStalk Protocol for adding machine language 
utilities to Basicsystem. It would bt helpful if ttiose ofyou write these utilities 
state in your documentation whether you have followed this protocol or not 
Refer to the DOStalk article for complete details if you are writing such 
routines. Here's a summary of tiie protocol: 

1. Use Basic.systetn's GETBUFR call to allocate memary for your routine. 

Be prepared to relocate your routine anyuhere; don't expect to be 
the first or only user of GETBUFR, 

2. Newer use Basic.systefli's FREEBUFR call; the only crash-proof way to 

free the buffers is to restart Basic.systeen. 

3. When connecting your routine to Basicsystem's CXTRNCMD vector or to 

Rpplesoft's f^MPERSPNO vector, save uhat's already in the vector and 
daisy-chain to it if the call is not for you. 

The DOStalk article tiiis originally appeared in included source code for a 
public domain TYPE command. This command displays text files on your 
screen or printer and demonsti-ates how to use tiie protocol. The command's 
only failing is tfiat it doesn't accept lower-case commands; something all 
added commands should do. Don't botiier to type in tiie source code from 
that article, however, Uie DOStalk TyP£ command was included on a recent 
disk distributed by the International Apple Core and consequentiy is 
available in user group libraries. The disk is /IAC.44, It also includes a 
lYoDOS version of File Cabinet an early public domain database program 
for the Apple II. 
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Extra 65C02 bulletins 

Your old chums at Beagle Bros just put out Extra K 
a dandy set of programs that let you use the extra 64K 
in a lie or 128K lie. They mention that if you use the 
program that puts variables into the extra 64K, you 
need to modify existing machine language routines 
for sorting arrays and strings. Do you have any tips on 
how to do this? 

I'm told that the 65C02 included in the enhanced 
ROM upgrade Kit will allow my Apple He to run cooler 
and slightly faster. Is this true? 

Do you know if the Sider hard drive performs well 
with bulletin board systems? I plan to put up a board 
for my department very soon, and would appreciate 
any input or tips from others who may already be 
using it for that purpose. 

Peter Chin 
Brooklyn, Pi.Y. 

Beagle Bros' ace programmers tell me they haven't 
figured out yet how to get machine language sorts to 
ujork with variables ^ored in awdiiary memory. 
They point out that if you're not in a hurry, sort 
routines written in Applesoft will work with Extra K. 

/ personally think the 65C02 is the most over- 
hyped item to come down the Apple U pike in some 
time. It's a nice Uttte chip, and it does run cooier, but if 
it produced no heat at all it wouldn't significantly 
affect the temperature inside an Apple ll-Plus or lie 
because of all the other stuff in there. Bob Sander- 
Cederlo/at Apple Assembly Une tells me there is one 
set of infrequently-used machine langmge instruc- 
tions that executes in 6 cycles rather than Z however, 
there is another set that executes in 7 rather than 6, 
so there's no netgain there. Programs written to take 
advantage of some new instructions in the 65C02 
could potentially run slightly faster; no programs 
that 1 know of however, other than SuperCalc 3A and 
the lie firmware, use the new instructions — including 
the enhanced He firmware. Bob also pointed out the 
chip is available from the manufacturer in versions 
capable of running faster than the fastest 6502, 
however, the Apple // is unable to take advantage of 
this capability without adding a special card. 

The Apple user group in Fhoenix had a newsletter 
article last month about setting up a bulletin board 
using a Sider and a FroDOS-based bulletin board 
system caHedQBBS H ($95 from Micro Data Products, 
5759 South Olathe Court, Aurora, Colo. 303-699- 
R61}. The gist of the article was that they were quite 
happy with the system, however, they admit it took a 
club member with bulletin board experience 30 to 
40 hours to get every thing set up as they wanted it 
The author of the article was Jerry Cline, who 
mistakenly let somebody put his phone number in 
the newsletter: 602-992-7035. 



Short end of joystick 

I have been enjoying Open-Apple since the first 
issue. 1 am, however, a little disappointed too. 1 own 
(and use a lot!) an Apple ll-Plus with shift key modifi- 
cation and a 16K RAM card. Almost everything you 
print is geared to the lie or lie 

1 would like to know such things as which of the 
newer chips I can use in my ll-Plus (and tips on 
installation), what advantages they could give me, 
and whether or not patches are available so that 1 can 
use such software as App/elVor^cs or other new 
software that was not designed with the ll-Plus in 
mind. 1 use Applewriter II and Screenwriter. Could 1 
use the new revised Apple Writer? Can I functionally 
do anything to make more than 64K available to the 
commercial software I use? I still have DOS and am 
contemplating getting a CP/M card I'm really beginning 
to feel left out when 1 look at the recent Apple 
software. 

I'm reasonabfy sure that Vm not alone among your 
readers. Do think about us ll-Plus people too. With 
that off my chest, I should say too that you are the 
best thing for Apple users since Softalk died. 

Hannah Lerman 
Los Angeles, Calif. 

The Apple ll-Plus is a classic. A lot of the stuff in 
Open-Apple works on a ll-Plus as well as a He or He 
—particularly programming information, liowever, 
as you point out, a lot of other stuff doesn't 

There is no advantage to using newer chips or 
adding memory to any version of the Apple II unless 
you also have software that will take advantage of 
the changes. Almost none will so —there 's very little 
to write or talk about in this area other than 
programming. 

Hew "productivity" software (word processors, 
spreadsheets, etc.) is written for the lie and lie 
because they have full keyboards, a standard 80- 
column screen, and a standard way of adding extra 
memory. Most of this kind of software, such as 
nmmr versions of Apple Writer, won't run on a II- 
Plus because it has no standards in these areas. On 
the other hand, a great deal of ll-Plus compatible 
software is being developed and released, but most 
of it is in other categories— education, games, 
utilities, and specialized applications. 

The idea of adding CP/M capability toyour machine 
is a good one if your are committed to the ll-Plus. 
Because CP/M was designed as a miversai" operating 
system to begin with, its programs adapt to various 
keyboard, memory, and 80-column schemes more 
easily. 

The day will finally come, however, when you will 
decide to get a newer computer. The Open-Apple 
information that now seems irrelevant to ll-Plus 
users will be much more meaningful then. 

Printing graphics 

How can 1 print out apicture fi-om inside a protected 
program? 1 use programs such as Pacemaker and 
Kidwriter in my classroom and I'd like to be able to 
print out my students' creations so the kids could 
take them home and show them off. 

Right now I use open-apple/control/reset to get 
out of these programs and Grafpak to print the 
picture that's left in memory, but the procedure is 
disruptive and the pictures are Ml of ugly distortion 
lines. Help. 

S.H.Gidi 
Allen Park, Mich. 



i use Apple Business Graphics on my Apple lie. It is 
a Pascal program and several years old. It is configured 
to print to an Apple Silentype or Qume printer. 
Although 1 can get it to print text to my Prowriter with 
the Qrappler card I can't get graphics to print I've 
contacted dealers in the past and get the story of 
expensive drivers 1 need to purchase. There must be 
an easier answer, 1 just haven't found it 

Dave Hamilton 
Lincoln, neb. 

Those distortion lines you get in graphics after 
pressing open-apple/control/reset come from a 
feature" of the lle/llc Monitor that destroys a couple 
of bytes on every page of memory as an aid to me 
dark forces of copy protection. 

There is a new kind of printer interface card on the 
market that solves the problems both of you are 
having. This kind of card has the power to take 
control of your computer no matter what kind of 
program is running— protected, Pascal or plain— 
and dump whatever is on your screen (graphics or 
text or both) to your printer. This kind of card comes 
with a button you press when you want to print 

One of these new cards is called Print-iti Its 
available for $199 from Texprint, 220 Reservoir St, 
needham heights, MA 02194 (800-255-1510/617- 
449-5808). I know of this card only through the 
company 's advertising. 

Another is called PingerPrint Plus. It's sold by 
Thirdware Computer Products, 4747 nw 72nd Ave, 
Miami, PL 33166 (305-592-7 522) for $149. Thirdware 
sent me one of its cards a couple of months ago to try 
out I like it Its ^button" is a small square of 
cardboard with a cute little fmgerprint on it The 
button is attached to a thin mylar cable that you can 
string through the lid crack on the top of your Apple. 
Stick the pre-gummed button somewhere handy 
and you're set 

When you press the button, the card grabs control 
of your machine and displays a menu. Prom here 
you can preview all of the Apple text and graphics 
pages and print any of them. The menu also allows 
you to change interface card parameters such as 
margins and line length; allows you to rotate, 
double, and crop hi-res graphics; allows you to print 
low-res, double high-res, mvced text and graphics, 
and color; allows you to jump into Applesoft or the 
Monitor; and allows you to choose whether the 
card's serial port or parallel port will be active (you 
can also choose both or neither). 

The card supports both serial and parallel printers, 
but comes with only one cable. A second cable is 
$28. Both cables are over 6 feet long, which is at least 
a foot longer than the cable that came with my 
Qrappler Plus. 

The only reservation I have about the card is that it 
isn't completely Grappler-compatible. The biggest 
thing I miss is the Grappler's "/YOT SELECTED" 
message, which appears when your printer isn't 
turned on or is out of paper or whatever. That little 
message is worth its weight in IBM software. I've 
sorely missed it for at least 20 panic-stricken minutes 
since I installed the Fingerprint Plus— time spent 
trying to figure out why programs that used to work 
fine were hanging up. The answer, of course, was as 
simple as "turn the printer on, stupid", but I'd rather 
have my interface card tell me that than have to 
figure it out for myself 

Another esoteric problem I had has to do with the 
control-I command character The program that 
prints Open-Apple mailing labels uses printer tabs. 
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The controi code for tab is a>nUoi'L 7b get control-! 
to a printer, fiowever, you have to change the 
interface card command character, which is ateo 
controi-/, to something else. Otherwise the card uAU 
eat them instead of sending them along to the 
printer (now you know why you couldn't get your 
printer's tab command to work, Alfle). The standard 
way to change the command character is to print a 
control ! control-something-else. The something 
else then becomes the interface card's command 
character. 

So far so good. But the Qrappler Plus reinitializes 
itself everytime you turn the printer on. Thus you 
have to do control-! control-something else after 
every FR^l The fingerprint Fius, on the other hand, 
doesn't reinitialize itself The second time you turn 
the printer on it sends your control-! to the printer, 
swallows your control-something else, and, if the 
n&df^aracteryousendisacontroldmracter (it was 
an escape in my case) charges the commmd char- 
acter a second Ume. How you have a mess on your 
hands, as well as a puzzle, 

!f you are writing your own programs, of course, 
all this is fixable, once you figure out what it going 
on. But if you are using commercial software that's 
Qrappler-compatible, you could end up with some 
problems. (Incidentally, the May tip from Bernard 
Goodman on getting a hex dump of what's going to 
the printer (page 59) was invaluable in solving this 
puzzle.) 

The manual that comes with the Fingerprint Pius is 
pretty good for printer-related documentation, which 
is notoriously bad, but not nearly detailed enough 
for a perfect world, In particular, it doesn't warn you 
In big letters on every page not to push the button 
while a disk drive is sauir^ something. In /act it 
doesn 't warn you about this at ali—even though it's 
an easy way to destroy the data on disks. 

Ml in sdl however, the advantages ofihe FlngerpHnt 
Pius compared to the Qrappler Plus are quite e)q)lidi 
while the disadvantages are esoteric. The Fingerprint 
Pius not only allows you to print from within any 
program, but it has several graphics^printing features 
the Qrappler Pius lacks. Ixfok at the price, too— on a 
features-per-dollar basis the Hngerprmt Pius looks 
to me like an exceptional card. 

Both sides win again 

I just wanted to add my two cents to the controversy 
over using the back side of single-sided disks. The 
di^ manufiicturers will tell you that only one side is 
certified; but in M since some drives write on the 
back of the disk and otIieTS on the fi^ont they don't 
know which side your disk drive is writing to. 
Therefore they have to certify both sides; witness the 
fact that there are "data holes" on both sides of the 
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There's a potential problem of dirtaccumulating in 
the dust jacket and then being released when the 
disk spins the "other" way, but I've yet to see data loss 
due to this in my six years of flipping floppies. 

Keep up the great work with Open-Apple, next to 
liUiMe, its my ^rite Apple reading. 

David Szetela 
Concord, Mass. 

/ hate to rq^rint letters in which people say they 
prefer I^Me to Open-Apple, but after last month's 
smart-aleck aaiamation point ejqmse (page 45), I 
owe them one. Just so you understand where this 
correspondent is coming from, he's MWtle's Man- 
aging Mtor, 



Having used the mini-assembler to start learning 
machine language, I purchased tie ProDOS Editor- 
Assemblen most^ because of its well^tten tutorial, 
tlowever, since there Is no provision for multiple 
ORQs in the program section of the source code. I 
haven't been able to enter even short data tables at 
absolute memory locations without using the Monitor 
or another file. Is there any technique around this 
limitation? 

Stephen Qale 
KeyportilJ. 

According to Don Lancaster's Assembly Cookbook 
for the Apple l!/!Ie ($2195 from Howard W Sams fif 
Co, 4300 West 62nd St Indianapolis, Ind, 46268), you 
can use multiple ORQs with EDASM. This book is 
based on E:DASM-it's a good introduction to using 
assembly language. Apple gave me a copy of EDASM 
at a ProDOS seminar ! went to a couple of years ago 
and it was so different from Uxe other assemblers !'ve 
used that I immediately pled it away and haven't 
seen it since, so ! don't know much about it. You 
might try calling or writing Lancaster, in care of 
Synergetics, Box 809, Thatcher, Ariz. 85552 602- 
428-4075. 

Speaking of Lancaster, he sent the following logo 
this month with the caption Ihis is a Lasemvfter 
image done with Applewriter on an Apple lie. Ask 
your local printer to estimsAe the typesetting cost on 
this for you. Be sure to wear good running shoes; 
you will need them." The image has been reduced 50 
percent 
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BRUN bug/More on RGB 

I am perplexed by something from the May issue of 
Open-Apple. Why do we have to switch SMQLRES on 
and off to make double hi-rcs work on an ROB 
screen? Is this a timing problem, or what? 

I'm wondering whether this is related to a problem 
I'm having witha double hi-res screen dump program 
1 wrote. When 1 BRUIi the program it hangs, but if I 
BLOAD and CALL it instead, it runs just fine. Here's a 
small test program that demonstrates die bug. It 
seems to hang when it reaches the main mem/aux 
mem flip: 

030g:BD BZ C0 5Tfi 5NGL.RES.0FF (dauble-res on) 

0303:80 00 C0 5Tfl COLB0.DN 

030G:BD 50 C0 5Tfl GRftPH.ON 

0309 :BD 57 C0 5Tfl HIRES. DN 

030C:8D 53 C0 Sin niXGR.DN 

030r:BD 01 C0 STfl STQRE80 

0312:8D 55 C0 STfl PftGEZ.ON 

0315 :fiO 00 20 LDfi J2000 



0318:20 Ofi FD JSR PRBYTE 
031B:BD 54 C0 STfl PPGEl.ON 
031E:RD 00 20 LDfl $2000 
0321:20 DR FD JSR PRBYTE 
0324 :G0 RTS 

Alain Toutant 
Ste-AngpIe-de-LavaL Quebec 

Your problem is actually a bug in the DOS 3.5 
BRUH command. The program doesn't hang until it 
gets to the KTS. 

When you BRUFia program, DOS loads your a>de 
and does a JMP to it from within a subroutine. The 
RTS at the end of your code is tafccn as the end of that 
DOS subroutine. 

Any program running under DOS 3.5 that is BRUH 
should save the value Uncle DOS has stored at byte 
43609 ($AA59). This vahie is critical to your program s 
finding its way home again, but it gets overwritten 
when DOS intercepts a character passing through 
the I/O hooks. If you save $AA59 before doing any 
input/output, and replace it before your final RTS, 
your problems will go away. Look at lines $4085 
and $409A of March's IfiCinERATOR (page 18) for an 
example. 

Poking the S/YGLKfiS and 80COL switches as 
shown in the May issue (page 56) shifts bits into two 
flags on the RGB card, which in turn teU &ie md 
which t;tdeo mode to display. In addUlon to the three 
modes discussed earlier (560 x 192 monochrome, 
140x192 l&color, andamixof560 and 140), it turns 
out there is also a fourth mode —160 x 192 in 16 
colors. This mode uses all 8 bits of each byte (two 4- 
bit pixels per byte), rather than 7 as the other modes 
do. Consequently, it is much easier to program. The 
first two pixels of line one are stored at $2000 in 
auxiliary memory, the next two pixels are in main 
memory, and so on across the line. 

here's the correct sequence for pokingtheswitdies 
to get any of the four modes (it doesn't matter what 
value you poke). The 80COL off and on switches are 
at 49164 and 49165 ($C00C-C00D) and the StiGLRES 
off and on switches are at 49246 and 49247 ($C05E- 
C05r). (note that &iGLRES off is the same thing as 
DBLRESon, u^ich is what I wish I had called this 
pair of switches last Ume. They are also known as 
At13, because they also control an output on the 
game port called annundator #3 J; 

RGB Control SequencBB 



5S0 X 132 


140 X 192 


5E0 & 140 


1G0 X 192 


oionoGhronie 


Ifi-color 


inixed 


IG-color 


80C off 


80C on 


80C off 


80C on 


DBL on 


DBL on 


DBL on 


DBL on 


DBL off 


DBL off 


DBL off 


DBL off 






80C on 


B0C off 


DBL on 


DBL on 


DHL on 


DBL on 


DBL off 


DBL off 


OBL off 


DBL off 


B0C pn 






B0C on 


DBL on 


DBL on 


DBL on 


DBL cm 



AU the above modes require that both DBLRES 
and SOCOL end up turned on. 

BEt/ilARE, programmers, of leaving DBLRES on 
and swit(Ming to 40-column text Users uAth RGB 
cards get a cotor text display in this situa^ that Is 
ofien unreadable if turned on by aoMent l/fHth 
DBLRESon, 40-aAumntextonRGB'equippedApiAes 
appears in combinations ofl6foreground'badcground 
colors. The display page in main memory holds the 
text and the display page in auxiliary memory holds 
color information. The first nibble of each color byte 
holds the color of the text (the foreground), the 
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second nibble holds the background color. If both 
na>bles hold the same value, the text blends into the 
background and becomes invisible. 

Token tinkering 

(n your June issue (page 42), you tell how the lie 
cassette commands point to the same location as 
the fif command. There is a simpler method than the 
one you give to distinguish between the commands. 
When Applesoft calls a command routine, the Y 
register contains an index to the command. The 
following three instructions will move the index into 
the A register and convert it into the command token 
($9A=SHLX)AD, $A7=RE:CAa, and so on, as listed in 
the June issue): 

TYfl 
SEC 
RDR 

Glenn Chappell 
Overland Park, Kans. 

tiere's a little program that's demonstrates C/iap- 
pell's technique: 

100 REM pol<e 5300 in page -3 ampersanci vector 
110 C$="3FG:00 03" 
120 GOSUB 500 

130 REM poke Chappell 's routine at 4300 
140 C$= "300:98 38 Gfi 4C Dfl FO" 
150 GDSUB 500 

1G0 END 

500 CS=C$+" N OgCSG" : REM S.H. Lam routine 
510 FOR 1=1 TD LEN(C$) 
512 : POKE 511+1, flSC(MID$(C$,Ml )+12B 
514 NEXT 

520 POKE 72,0 : CfiLL -144 
530 RETURN 

After running this program, enter the 6 possible Uc 
ampersand commands (SfiLOAD, RECALL 5T0/?E, 
LOAD, SAVE, A'j direcUy on a Uc keyboard. The 
program causes mch to print its associated token on 
the screen. 

Make byte low 

1 am finally gritting my teeth and attempting a 
wholesale conversion from DOS 3.3 to FroDOS. One 
of the most heavily used word processors in our 
company is format // Enhanced, because of its easy 
on-page orientation and the ability to do columns for 
script writing. 

However, the ProDOS COnVERT utility inexplicably 
sets the high bit on all the text files coverted over, 
format uses the high bit so converted files are a 
mess. Several phone calls to Kensington Microware 
resulted in a vague commitment to work on it 
sometime and Apple referred me to my local dealer 
(Ho, Ho). Is there a way to fix COMVEFT? Or is there a 
nice simple little program that can take a converted 
file and turn off the high bit in every byte? 

By the way, I haven't noticed any mention of it in 
ppen-i^iiple, but one of the key reasons for my 
switch to the combination of ProDOS and the He 
enhancement is the wonderful SuperCaic 3A This is 
one of the best indications yet of the increasingly long 
life ofthell series. 

nip Baldwin 
Salinas, Calif. 

7^e the basic Basiccopy program from the front 
part of this issue. Add the S. W. Lam routine near the 
beginning of the program (see the February issue, 
page 12, for details on this; the answer to the last 



letter includes the actual rouUne) to load the following 
machine language stuff at $300: 

C$="300:18 flD D7 BE 85 3C SO DB BE 

85 3E flO D8 BE 85 3D 6D DC 

BE B5 3F m 00 Bl 3C 29 7F 

91 3C 20 Bfl FC 30 FS 60" 

How add a CALL 768 to the copy program between 
the BLOAD and the 5SAVE. The program will then 
load a file and call the machine lanugage subroutine 
at 768 ($3001 That routine zips through the image of 
the file in memory and turns off all the high bits. 
When it's done, the main program will resave the file. 

ProDOS 40-track bug 

In the April Open-Apple you published some 
patches to make ProDOS 111 and FILER H work with 
40-track drives. You point out that the patches are 
based on Worth and Lechner's patches in Beneath 
Apple ProDOS. There seems to be an error in both. 
The change of $23 (35) to $28 (40) makes sense but 
shouldn't $18 ($0U8 = 280) be changed to $40 
($0140 = 320) instead of $39 ($0139 = 313)? 

Worth and Lechner claim the patches will allow for 
320 blocks instead of 280. 1 have formatted disks 
both ways and inspected them with a disk zap utility, 
and it seems to me that using $28 and $39 formats 



the disk for 40 tracks but only allows for 313 of 320 
blocks to be used. Am I right? 

A different question: you note parenthetically that 
block 2 = track 0, sector IL; but Wbrth and Lechner's 
Table 3.1 shows block 2 in sectors 8 and 10. Who's 
right? 

Cjeorgeiyiutki 
La Plume, Penn. 

Vbu're right about the patches in our April issue 
(page 32). Where you see $39 change it to $40. Penal 
this change in your back issue now, everybody. 

The confusing thing about Worth and Lechner's 
Tsible 3.1 in Beneath Apple ProDOS is that it relates 
ProDOS blocks to physksd disk sectors. The physical 
sedors on DOS 3.3 and ProDOS disks are identical; a 
diskzap utility based on either operaUngsystemcan 
access the other's disks. But Worth and Lechner's 
table is meaningless to anyone trying to examine a 
ProDOS block with a DOS 3.3 zap utility because 
DOS 3.3 sector numbers are logical numbers: a little 
table inside DOS is used to change them to physical 
sector numbers just before accessing a disk. 

The shaded box on this page has a table similar to 
Worth and Lechner's that converts ProDOS blocks to 
DOS 3.3 tracks and sectors, (tiote that since ProDOS 
blocks are twice as big as a DOS 3,3 se(ior, it takes 
two sectors to make one block.) 
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Basicsystem trace bug 

Both versions of Basicsystem contain an ephemeral 
but interesting bug that suddenly triggers trace mode 
and just as suddenly disappears. 

Consider the following 4-liner by J.R Wakefield 
from the "Letters" section of the April 1985 Nibble, 

10 SET PRINT 

20 IF RI="fi" THEN FLASH : PRINT "ERROR" : GOTO 40 
30 FLR5H : PRINT "QK" 
40 NORnflL : GOTO 10 

If an upper case "A" is pressed, tracing begins. All 
other input produces a normal response. Abnormal 
tracing ceases when another text mode command is 
encountered. 

Tracking the bug to its lair took considerable effort 
and will be the subject of Disassembly Lines column 
in the December 1985 or January 1986 nibble, for 
now, here's a summary of the problem and a recom- 
mended solution. 

Unlike DOS 3.3, Basicsystem bullies the Applesoft 
new statement and trace handler (riEWSTT, $D7D2- 
$DB56) into kicking trace information back to Basic- 
.system. Basicsystem uses the trace information as a 
signal that a new command is being executed. It 
checks out the token of the command for screening 
and pre-processing. !t does all this by making sure 
that the Applesoft trace flag (TRCFLQ, $r2) is always 
on (high bit set). The true status of trace mode is kept 
within Basicsystem's global page (DTRACE, $BE41). 
By checking this byte Basicsystem detennines whether 
to pass the tracing information on to the screen or 
not 

Basicsystem also stores an image of the normal 
trace character, which happens to be (ASCII $A3). 
Whenever anything is printed, Basicsystem, like DOS 
3.3, intercepts it Basicsystem, however, checks to 
see if the source of the information is Applesoft's 
trace mode by first checking if the pound sign is 
being output, and if so, by determining whether the 
output originates from MEWSTT. 

After Applesoft processes a FLASH command, 
trace's leading pound sign acquires an ASCII value of 
$E3 instead of $A3. Thus, when Basicsystem sees a 
FLASH token, it changes the trace character image 
from $A3 to $E3. But, unfortunately, not all contingen- 
cies are taken into account 

When Applesoft executes an IF statement trace 
data is sent to Basicsystem as usual. However, if the 
formula following the IF statement is true, Applesoft 
will execute the command following THEM without 
outputting any additional trace information. Thus, if 
FLASH is executed inside an IF-THEH statement 
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Basicsystem never sees die FLASH token and doesn't 
change the b^ace character image from $A3 to $E3. 
Consequently, Basicsystem doesn't recognize the 
following flashing trace data for what it is and sends it 
on to the screen. 

The dynamics of this adverse interaction between 
Applesoft and Basicsystem is complex and illustrates 
that debugging involves more than the mere exami- 
nation of code segments. 

Fixing the bug is as simple as realizing that the 
concept of a trace character image is unnecessary. If 
output comes from MEWSTT, the pound sign must be 
the character being processed. With this in mind, 
here is my patch for Basicsystem 11 (for 10 change 
the starting address to $9E5B): 

9£:2C:46 BE 3F SE 

9E30:Bfl 80 04 10 C9 12 00 0R 

9E3B:B0 85 01 C9 DB DO 03 SB 

9f:i0:B0 7A GB Efi Efl Efi 

1 Stress that this fix is no substitute for revising 
Basicsystem's output handler. If someone would 
rather avoid the bug than correct it (a mortal sin for 
hackers), just be certain that Applesoft commands 
pre-processed by Basicsystem (e.g. TRACE, nOTRACE, 
nORMAL, inVERSE, FLASH, RESUME) do not imme- 
diately follow a THEM. C ^ M U 

Sandy Mossberg 

Rye Brook, riY 

Bugs and the future 

Here is an answer for "Problem too complex" 
(February, page 15). A="A" internally uses a zero page 
temporary string descriptor for the literal "A." This 
descriptor is freed upon successfrjl completion of the 
statement However, the statement does not complete 
because it is in error. OnERR redirects the program to 
execute the statement again. Soon the limited number 
of internal string descriptors is exhausted. FORMULA 
TOO COMPLEX is generated when no more are 
available. A$=A doesn't use an internal zero page 
temporary stingdescriptor. Too many internal nested 
string generations will also produce the same result 

With regard to "Interrupts and the Sun " (June, page 
46), ProDOS does use $45! The ProDOS Technical 
Reference Manual (page 110-111) describes the 
locations to be used by intelligent controller boards, 
such as the one used with the ProFile. The ProFile 
may be called directly with the following memory 
locations set 

$42 command (0=status, I=read, 2-write] 
$43 unit number (dsssxxxx, d-drive, sss=slot] 
$44-145 buffer painter [512 byte area) 
$46- $47 block number 

I have Avritten routines to directly access the ProFile 
using this layout and JSR $CsXX, where s is the slot 
number and XX is the value at $CsFF. notice that die 
last 5 of the 6 bytes are the same as the ProDOS 
Read_Block ($80) and Write_Block ($81) MLl calls. 
The error codes returned by the ProFile ROM in the A- 
reg are exactly the same as the ProDOS MLl codes 
($27=1/0 ERROR, $28=riO DEVICE COnriECTED, 
$2B=WRITE PROTECTED), with carry set So, yes, $45 
is used by ProDOS. By the way, you can see why DOS 
3.3 doesn't support the ProFile, since the I/O is done 
in units of 512 byte blocks. 

So why won't DOS 3.3 be supported on ftiture 
versions of the Apple 11? Well, we all complained that 
DOS 3.3 didn't have enough features, had enough 
bugs, and could not easily handle a number of 
significant new devices (hard disks, interrupt genera- 
tors, etc). Everyone and his uncle had a patch to DOS 
3.3 for somediing or other. And Apple Computer 



listened. Thus, along came ProDOS. The amazing 
part is that the Applesoft interface is very nearly the 
same (and Applesoft is even the same; I converted 
Softgraph from So/talk with less than a half dozen 
changes). In a nutshell, ProDOS has all of the capabil- 
ities that we wanted in DOS 3.3 (but really could not 
be put in DOS 3.3), fixes many problems (how many 
years to fix append), and is expandable for the ftjture. 

I believe the potential for DOS 3.3 is far too limited 
for the ftiture of the Apple II computer. The DOS 3.3 
append error was almost unfixable. How many bugs 
still exist that will not be found until someone 
attempts to use the code on a device that was not 
originally supported (like a 3-1/2 inch Sony floppy 
with variable speed depending on track number)? 

If there is a future for the Apple II, and if that friture 
includes faster CPU chips (65816), more memory, 
larger disk devices, and extended human interface 
capabilities (mouse and graphics), then DOS 3.3 just 
does not make it ProDOS is a better base. 

With the departure of the Apple 111 and SOS, 
ProDOS is the only good operating system left at 
Apple Computer. The Mac file handling has been the 
pits. It is even worse than the days of early DOS 3 (at 
least that is what 1 read, and of course, only the bad 
stufFgets printed). I used to have all kinds of problems 
with DOS 3.3 (it had to be babied). 1 don't have any 
problems with ProDOS. That means a lot when I have 
thousands of hours of work invested on my ProFile. 
not one bad block, not one lost frack. not one I/O 
error. And the Apple Mouse worked right away And 
the extended memory worked right away And the He 
enhancement worked right away Maybe 1 am spoiled. 
When I buy sometiiing, I expect it to work. All of my 
ProDOS products work. Can this be said about DOS 
3.3? What kind of changes need to be made to DOS 
3.3 to support the 65816? 

Ken Kashmarek 
Eldridge, Iowa 

Thanks for your help with FOmVlA TOO COMPLEX 
and $45. I suspect interrupts are disabled when 
FroDOS calls intelligent controller boards and that's 
why this call is allowed to use $45. Direct calls such 
as yours should also either disable interrupts or plan 
not to use them on U-Fluses and original Ues, 

I agree with your comments on ProDOS. As hard 
disks and other high-capacity storage devices come 
down in price most other people will agree with you, 
too. however, you have to admit that the biggest 
problem with ProDOS and Basicsystem right now is 
that we just don't know what bugs lurk within them. 
There certainly appear to be a few —as is expected in 
any major piece of software. 

Yet healthy enthusiasm for ProDOS is no reason to 
abandon all the effort that's gone into learning about 
DOS 3.3. The problem is not that DOS 3.3 doesn't 
support the ProFile, but that the ProFile— alone 
among hard disks for the Apple II family— doesn't 
support DOS 3.3. 7?ie technical problems are solvable; 
Apple in its arrogance toward the market simply 
decided not to solve them. But compare ProFile sales 
to those of other hard disks for the // and you'll see 
that Apple, in this case at least is paying for its 
disregard of the customer, 

DOS 5.5 has bugs, sure, but why, just when we 
fmally know what they are and have thousands of 
people who know how to program around them, 
should we dump it? U s a perfectly good operating 
system for many^ many floppy-based applications. I 
continue to insist that any future Apple that can't 
boot DOS 5.5 is just an Apple, too; it's not a member 
of the Apple U family. 



